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Abstract 
This document defines a hierarchical method of encoding Join/Prune 
attributes that provides a more efficient encoding when the same 
attribute values need to be specified for multiple sources in a PIM 
Join/Prune message. This document updates RFC 5384 by renaming the 
encoding type registry specified there. 
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1. Introduction 


PIM Join attributes as defined in [RFC5384] allow for specifying a 
set of attributes for each of the joined or pruned sources in a PIM 
Join/Prune message. Attributes must be separately specified for each 
individual source in the message. However, in some cases, the same 
attributes and values need to be specified for some, or even all, the 
Sources in the message. The attributes and their values then need to 
be repeated for each of the sources where they apply. 


This document provides a hierarchical way of encoding attributes and 
their values in a Join/Prune message so that if the same attribute 
and value is to apply for all the sources, it only needs to be 
specified once in the message. Similarly, if all the sources in a 
Specific group set share a specific attribute and value, it only 
needs to be specified once for the entire group set. 


This document extends [RFC5384] by specifying that the encoding type 
defined there also applies to Encoded-Unicast and Encoded-Group 
formats. This document also updates [RFC5384] by renaming the "PIM 
Encoded-Source Address Encoding Type Field" registry to "PIM Address 
Encoding Types". The content of the registry remains the same. The 
encoding type used for Join attributes is, however, still limited to 
use in Join/Prune messages. Note that Join attributes, as they are 
referred to in [RFC5384], also apply to pruned sources in a Join/ 
Prune message. Thus, the more correct name "Join/Prune attributes" 
will be used throughout the rest of this document. 


This document allows Join/Prune attributes to be specified in the 
Upstream Neighbor Address field, and also in the Multicast Group 
Address field, of a Join/Prune message. It defines how this is used 
to specify the same Join/Prune attribute and value for multiple 
Sources. This document also defines a new Hello Option to indicate 
support for the hierarchical encoding specified. 


2. Requirements Notation 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. Hierarchical Join/Prune Attribute Definition 


The format of a PIM Join/Prune message is defined in [RFC7761] as 
follows: 
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0 1 2 3 
0 1.2.2 4 506 7.9.9 0 12 3.4 5.6 7 8 9 0 1.2 3.45 6. 7989. 9 Q0 I 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
|PIM Ver| Type | Reserved | Checksum 
T—R—4—4—4-4-4-t-t-----t-t-t-t-t-—t-—L-—t-4— ——4—4-4-4-4-4-4-4-4 
| Upstream Neighbor Address (Encoded-Unicast format) | 
T—R—4—4-—4-—4-t-t-t-t----t-t-t-t-t-—t-—t-—L-4—4—4—4—4-4-4-4-4-4-4-4 
| Reserved | Num groups | Holdtime 
a E A SS Si SS Ss es es ee 
| Multicast Group Address 1 (Encoded-Group format) | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Number of Joined Sources | Number of Pruned Sources | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Joined Source Address 1 (Encoded-Source format) | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
*—R—4—4-—4-4-.-t--t-----t-t-t-t-t-—t-—t-4— 4 —4—4-4-4-4-4-4-4-4 
| Joined Source Address n (Encoded-Source format) | 
T—R—4—4—4-—4-4-t-t-t-----t-t-t-t-—t—L-L- 4-4 —4—4-4-4-4-4-4-4-4 
| Pruned Source Address 1 (Encoded-Source format) 
fs ee ee vg ay or at dg ee em nad ne a 
PO TIU ee ee eee 
Pruned Source Address n (Encoded-Source format) | 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


+ 一 + 一 一 


*—R—-.—R—L--.-4—4-.-.-4-—4L-4- .- LM. 44-4 44-4 
| Multicast Group Address m (Encoded-Group format) | 
G ma den Sea e ea Geak Saa Aaa aS a tata S e S E E S A E a A E A BM 4B 
| Number of Joined Sources | Number of Pruned Sources | 
P a es ato Sen GE A ri i E 
| Joined Source Address 1 (Encoded-Source format) | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | 
v IUE REPE 
| Joined Source Address n (Encoded-Source format) | 
FoF HHH tot mtr ta toto toto ta totaota ta MÀ —.-x- L4 B4B BÀ t 
| Pruned Source Address 1 (Encoded-Source format) 

*—R—-R—R—L-x-.-4—L--.-4-—4L—4-— - LM. BM BB t 
| | 
—— —— —— 
| Pruned Source Address n (Encoded-Source format) 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
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The message contains a single Upstream Neighbor Address and one or 
more group sets. Each group set contains a Group Address and two 
Source lists: the Joined Sources and the Pruned Sources. The 
Upstream Neighbor Address, the group addresses, and the source 
addresses are encoded in Encoded-Unicast format, Encoded-Group 
format, and Encoded-Source format, respectively. This document 
extends the use of the source address encoding defined in [RFC5384] 
to also apply to the Upstream Neighbor Address and the Group Address 
fields (see Section 4). 


For a Join/Prune message, a hierarchy of Join/Prune attributes is 
defined. Attributes at the highest level, which is the least 


Specific, apply to every source in the message. These are encoded in 
the Upstream Neighbor Address. Attributes at the next, more-specific 
level apply to every source in a group set. They are encoded in a 


Group Address. And finally, there are attributes that apply to a 
Single source and are encoded in the source address as defined in 
[RFC5384]. 


The complete set of attributes that apply to a given source is 
obtained by combining the message-wide attributes, the attributes of 
the group set that the source belongs to, and the source-specific 
attributes. However, if the same attribute is specified at multiple 
levels, then the one at the most specific level overrides the other 
instances of the attribute. Note that the set of attributes and 
their values is formed before processing the attributes. Hence, a 
value that is invalid for a given type might override a valid value 
at a higher level. 


As an example, say that for a given source, we have attributes T 1 
with value V 1, T 2 with value V 2, and T 3 with value V 3. Also 
assume that in the Group Address of the source's group set, we have 
attributes T 1 with value V 6 and T 4 with value V 4. And assume 
that we in the Upstream Neighbor Address have encoded the attributes 
T 1 with value V 7, T 4 with value V 8, and T 5 with value V 5. The 
attributes applied to the given source will be T 1 with value V 1], 

T 2 with value V 2, T 3 with value V 3, T 4 with value V 4, and T 5 
with value V 5. Here we have T 1 with different values at each 
level, so we use the value specified at the source level. Also, we 
have T 4 with different values at the group and message levels, so we 
use the value at the group level. Here it could be that V 1 is not a 
valid value for T 1, but it still overrides the values at the higher 
levels as we do not process the attributes until after forming the 
set. 


Note that Join/Prune attributes are still applied to sources as 


specified in [RFC5384]. This document does not change the meaning of 
any attributes; it is simply a more compact way of encoding an 
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attribute when the same attribute and value applies to multiple 
Sources, e.g., with the example above, we would have the exact same 
meaning if we instead had encoded all the attributes T1, ..., T5 with 
the respective values V1, ..., V5 in the source address. 


4. PIM Address Encoding Types 


Addresses in PIM messages are specified together with an address 
family and an encoding type. This applies to Encoded-Unicast, 
Encoded-Group, and Encoded-Source addresses. The encoding types 
allow the address to be encoded according to different schemes. An 
encoding type indicates how an address is encoded irrespective of 
address type, Encoded-Unicast, Encoded-Group, or Encoded-Source. It 
is possible that there will be future encoding types that do not 
apply to all address types though. This means that as currently 
defined, 0 is native encoding [RFC7761], and 1 is Join/Prune 


attributes encoding [RFC5384]. Note that as specified in [RFC5384], 
a type 1 Encoded Address MUST contain at least one Join/Prune 
attribute. 

5. Hierarchical Join/Prune Attribute Hello Option 


A PIM router indicates that it supports the mechanism specified in 
this document by including the Hierarchical Join/Prune Attribute 
Hello Option in its PIM Hello message. When this new Hello Option is 
included, it MUST also include the Join Attribute Hello Option as 
Specified in [RFC5384]. The format of the Hierarchical Join/Prune 
Attribute Hello Option is defined to be: 


0 1 2 3 
Ql 2345 6.789 0123450678 90172 34 5 6 7:8 9 Q' 1 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

| OptionType = 36 | OptionLength = 0 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


OptionType = 36, OptionLength = 0. Note that there is no option 
value included. 


A PIM router MUST NOT send a Join/Prune message with Join/Prune 
attributes encoded in the Upstream Neighbor Address or any of the 
group addresses out of any interface on which there is a PIM neighbor 
that has not included this option in its Hellos. Even a router that 
is not the upstream neighbor must be able to parse the message in 
order to perform Join suppression and Prune override. 
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6. Security Considerations 


This document specifies a more compact encoding of Join/Prune 
attributes. Use of the encoding has no impact on security aside from 
using the encoding in [RFC5384]. For instance, an attack with a 
forged message with certain attribute values is equally difficult 
independent of which encoding is used. If an attribute that applies 
to the entire message is wrong, then that may cause an issue for all 
the sources in the message. But without this encoding, one would 
instead include that attribute for every single source, and that 
would also cause an issue for all the sources in the message. 


7. IANA Considerations 


IANA has renamed the "PIM Encoded-Source Address Encoding Type Field" 
registry to "PIM Address Encoding Types". 


The Hierarchical Join/Prune Attribute (36) has been added to the 
"PIM-Hello Options" registry. 
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